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(54) Tide: GENTOATING MEETING REQUESTS AND GROUP SCHEDULING FROM A MOBILE DEVICE 
(57) Abstract 

The present invention includes a mobile device (3) which 
provides the user with the ability to schedule a meeting request 
from the mobile device (3) itself. The mobile device (3) creates an 
object representative of the meeting request and assigns the object 
a global identification number which uniquely identifies the object 
to other devices (4, 10, 13) which encounter the object. In addition, 
the mobile device (3) in accordance with one aspect of the present 
invention provides a property in the object which is indicative 
of whether the meeting request has already been transmitted. In 
this way, other devices (4, 10. 13) which encounter the meeting 
request are capable of identifying it as a unique meeting request, 
and of determining whether the meeting request has already been 
transmitted, in order to alleviate the problem of duplicate meeting 
request transmissions. 
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GENERATING MEETING REQUESTS AND GROUP 
SCHEDULING FROM A MOBILE DEVICE 

BACKGROUND OF THE INVENTION 
Mobile devices are small electronic computing 
5 devices often referred to as personal digital 
assistants. One such mobile device is sold under the 
trade name Handheld PC (or "H/PC") based on a Windows 
CE brand operating system provided by Microsoft 
Corporation of Redmond, Washington. While a wide 
10 variety of computing tasks and applications can be 
performed by such mobile devices, personal information 
managers (PIMs) are particularly well suited to mobile 
devices . 

PIMs typically comprise applications which enable 
15 the user of the mobile device to better manage 
scheduling and communications, and other such tasks. 
Some commonly available PIMs include scheduling and 
calendar programs, task lists, address books, and 
electronic mail (e-mail) programs. Some commonly 

2 0 commercially available PIMs are sold under the brand 

names Microsoft Schedule+ and Microsoft Outlook and 
are commercially available from Microsoft Corporation 
of Redmond, Washington. For purposes of this 

discussion, PIMs shall also include separate 
25 electronic mail applications, such as that available 
under the brand name Microsoft Exchange. 

It is also common for mobile devices to be used 
in conjunction with a desktop computer. For example, 
the user of a mobile device may also have access to, 

3 0 and use, a desktop computer at work, at home, or both. 

A user may typically run the same types of PIMs on 
both the desktop computer and the mobile device 
(although the particular versions of the PIMs may be 
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somewhat different from the deskton . 

n'obile device) . Thus it computer to the 

the mobile device to ^ ""-^ "^"^ advantageous for 

Therefore, it is advant. ""^^ desktop, 

-biie device ^n/TCl^Z t ^^^^ °" 

- ^o-date inflation, relarle:! Tf^TherhL^^^^ 

changes to the pims have been ™J "^^^^^^ recent 

device or the deskton °" 

aesktop computer. Th<i. ,^ 

the two contain the .L, f that 
-^e..ea to a. sync Jo^ /atTon ^"^°™-ion is 

caien^:::"::" srr:,.""" ™ = 

- ^-e„.a I at a^tcteX '-"-"^^^ 
application) are trarIi^^ / ^ scheduling 

^" order to generate a m»^^ • 
typicauy interacts „un the T.T^'"'' 
through a user intarface The '"'"'''"''"^ application 
t- user With a ..Zu.yZ ^^ecMT^" ^"^""^^^ 
parameterize the .eetin, Uest p:"^:: ""^ T 
0 user interface typically allows the user tT . 
date and time (and often a clac», . ^ 

i= to be held The ""^ "^""^ '"^"i-'S 

allows the user to selecV^ ' 

^ a-^""? °f attendees that 
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the user wishes to attend the meeting, to enter some 
textual description of the meeting, and to specify 
whether the meeting is for only a single date, or is a 
recurring meeting (i.e., whether the meeting is to 
5 occur only on one date, the 15*"^ of every month, the 
first Monday of every month, every Monday, etc.) . 

Based on this information, the scheduling 
application creates an object which is representative 
of the meeting and enters it on the user's calendar as 

10 an appointment. Such objects are typically defined by 
a number of properties, some of which are defined by 
the user input information which the user provides 
while generating the meeting request. The meeting 
object also contains a critical time stamp (UTC) which 

15 is updated whenever a critical change is made to the 
meeting object, such as changes to the start or end 
date or time, changes in the location, etc. 

Since other people are identified as attendees, 
the appointment entered on the calendar is viewed as a 

20 meeting and the scheduling application typically calls 
methods exposed by an electronic mail application in 
accordance with messaging application programming 
interfaces (MAPI) , or other APIs which are a set of 
well documented, published interfaces commercially 

25 available from the Microsoft Corporation of Redmond, 
Washington. 

In response, the electronic mail application 
creates another object (an electronic mail meeting 
request object) indicative of the meeting request and 
3 0 the electronic mail application (or suitable 
transport) formats this electronic mail meeting 
request object into a well defined electronic mail 
message suitable for transmission. In doing so, the 
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pi LTL : ""^"^"^ also 

placed the electronic .ail meeting request object 

The electronic .ail application then interacts with 
a specr£.ed transport and transports the electronic 
mail meetino recm^c^h r^Kn^^^ ^ -^^^^^onxc 
it to . '^^.'^^^'^ ""^l*" ^° = network which routes 

electrontc '""^""'^ attendees. i„ doing so. the 
IIZIT I . "^^"=^"°'> typically accesses an 

address book stored in a database to obtain the fully 
^a if.ed electronic .ail address for the attendees 
This IS also typically done by calling >ftpi or other 
suitable API methods associated with the database 
storing the address book. The generation ofthe 
™eet.ng object and the creation of the electronic .ail 
meeting request object will be referred to herein 
collectively as creating a meeting request 
the ™t attendees then typically respond to 

crltiTl t' originator. s 

with tH '""^ '"""^ """"^ (unmodified, along 

".th the response. The response also includes I 
recxp.ent critical ti™= stamp and an indication of the 

recipient's response fe a 

P^^se (e.g., accept, decline, 

tentative, etc.). The recipient critlr-^i • 

. , , >— "-fj-ent critical time stamo 

IS updated by the r-er--! r^-i / 

y tne recipient (potential attendee) 

Th.s allows the user to reliably order receipt of 
multiple versions of the same meeting <e.g.. where the 
orxgxnator changes the time, date or location of the 
.eetrng such that multiple meeting requests are 
generated, . It also allows the originator to reliably 
order receipt of responses and ensure that eaci 
response correlates to the most recent version of the 
meeting. 

The response is then trans.itted "back to the 
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originator (e.g., the sending computer). The 
electronic mail application and scheduling application 
on the originator then typically process the response 
(or responses) accordingly. For example, the 

originator stores, for each recipient (or potential 
attendee) the recipient critical time stamp in a table 
along with each recipient's response code (which is 
indicative of the accept, decline, tentative 
response) . The two commercially available PIMs 
identified above (the Microsoft Scheduler and 
Microsoft Outlook brand PIMs) are examples of PIMs 
which support the features discussed above. 

Meeting cancellations, and exceptions to 
recurring meeting must also be handled. For example, 
15 the PIMs may allow scheduled meetings to be cancelled, 
and allow a variety of exceptions to a recurring 
meeting pattern. 

Scheduling of meeting requests as described above 
has, to date, only been supported by desktop computers 

2 0 or laptop computers which are fitted with a hard disk 

drive or other, high capacity memory mechanisms, or by 
low intelligence terminals which are permanently 
attached to a server or other similar computer which, 
itself, contains a high capacity storage device. The 
25 ability to schedule a meeting request from a mobile 
device is simply unavailable. While some current 
mobile devices are provided with PIMs that allow the 
user to view meeting requests, and to view meetings 
which have already been scheduled, current mobile 

3 0 devices do not allow the user to generate a meeting 

request from the mobile device itself. 

A number of significant obstacles present 
themselves when attempting to provide the user with 
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ZLl/T ^-""^"S a -"ing rarest fro. a 

™ob.le d,v.ce. Meeting cancellations and exceptions 
recurring meetings ™ust be handled. Also I 
Significant problem arises with respect to' the 
possibility Of transmitting duplicate leting 

ae~d b 1 "'"^ '"^"^"^ — " " 

an Pl« " °" necessarily be created with 

all PlMs, they do present a potential problem which 
must be considered. Por example, if the user of the 
mobile device were able to generate a meeting request 
a meeting object would first be entered on the 
calendar of the mobile device. The electronic mail 
application on the mobile device would then create a 
corresponding electronic mail meeting request object. 

with LTv " synchronized 
With the desktop computer, the meeting object would be 
synchronized with the calendar object store on th! 
desktop computer and the electronic mail 
request Object would be synchronized to the oes.top 
20 outbox. The desktop computer, would recognize th! 
electronic mail meeting request object in its outbox. 
format it for transmission, and transmit it over the 
network. Further, synchronizing the meeting object to 
the calendar of the desktop computer may result in 

ZT:. 

creaned and transmitted by the rf^=^Qirhor^ 

aesktop computer. This 

request -""^ 
"quest Objects being created (one by the mobil! 

device. and one by the desktop computer 

30 synchronization) and transmitted. under 



meeting 



one by the desktop computer after 
1) and transmitted. under that 

scenario, potential attendees would receive two or 
more meeting requests, and may respond to both This 
would create duplicate responses to what • was intended 
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to be a single meeting request. 

A similar problem may occur if a meeting request 
were generated in a conventional manner (on a desktop 
computer) for instance, and was then synchronized to a 
mobile device having the capability of generating and 
transmitting meeting requests. The meeting object on 
the desktop calendar would be synchronized to the 
calendar of the mobile device. The mobile device 
might then recognize the meeting object synchronized 
from the desktop. and create an electronic mail 
meeting request object and attempt to transmit the 
object. This would result in substantially the same 
problem -- duplicate meeting requests and duplicate 
responses for what was intended to be a single meeting 
l5 request . 

Further, if the user of the mobile device coupled 
the mobile device for synchronization with more than 
one desktop computer (e.g., a home computer and work 
computer, if the mobile device were provided with this 
2 0 capability) the same problem would result. In that 
instance, and using conventional architecture, both 
desktop computers would synchronize with, and 
recognize, the meeting object and the electronic mail 
meeting request object from the mobile device. The 
25 desktop computers would both potentially create 
additional electronic mail meeting request objects and 
transmit them to the potential attendees. Again, 
this would result in many different meeting requests 
and responses being transmitted for what was intended 
30 to be only a single meeting request. 

In addition, if mobile devices were provided with 
the capability of being connected directly to one 
another, and communicating with one another, without 
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going through a desktop or similar computer, the 
meeting request could be generated by one mobile 
device, responded to by another mobile device, and 
scheduled on both mobile devices. However, the next 
time the first mobile device is synchronized with the 
desktop computer, that computer might again recognize 
the meeting object synchronized from the calendar of 
the mobile device, create another electronic mail 
meeting request object and transmit the electronic 
mail meeting request object. Thus, a significant 
problem potentially exists with respect to the 
generation of multiple meeting requests. 

Of course, similar problems also result from 
critical changes to the meeting object on either the 
15 desktop computer or the mobile device. This will 
cause unwanted duplicate electronic mail meeting 
requests in a similar fashion. 

Additional problems also present themselves 
simply by the fact that conventional mobile devices 
20 have a memory capacity which is significantly less 
than that of a desktop computer or similar computer. 
Thus, problems arise with respect to storing address 
books on the mobile device itself which contain the 
fully qualified electronic mail address of all 
25 potential attendees. 

Further obstacles present themselves because many 
desktop computers on which the meeting request must be 
processed have different scheduling applications. 
Therefore, the meeting request generated by the mobile 
30 device may be incompatible with scheduling 
applications which it encounters. 

In addition, localization of meeting requests can ' 
present a problem. For instance, in some localities. 
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it is conventional, when writing a date, to place the 
month first, the day second and the year third. In 
other localities, other orders are conventional. 
Further, a textual description which describes the 
5 meeting, and which accompanies the meeting request, 
may need to be rearranged to conform to local 
convention. Also, meeting requests can be generated 
in one time zone and transmitted to recipients in 
other time zones. This can tend to be confusing. 
10 The present invention addresses some or all of 

these obstacles . 

SUMMARY OF THE INVENTION 
The present invention includes a mobile device 
which provides the user with the ability to schedule a 
15 meeting request from the mobile device itself. The 
mobile device creates an object representative of the 
meeting request and assigns the object a global 
identification number which uniquely identifies the 
object to other devices which encounter the object. In 
20 this way, other devices which encounter the meeting 
request are capable of identifying it as a unique 
meeting request in order to alleviate the problem of 
duplicate meeting request transmissions. 

In accordance with another preferred feature of 
25 the present invention, an electronic mail application 
or calendar application on the mobile device obtains a 
fully qualified electronic mail address for the 
potential attendees from an abridged address book or 
directory stored on the mobile device itself. This 
3 0 alleviates problems associated with the storage 
capacity of the mobile device. 

In accordance . with another preferred embodiment 
of the present invention, the mobile device creates 
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the meeting object and the electronic a,ail .eetinc 
request object usinq a set ^ ■ "'eetmg 

J Sing a set of properties which ar^ 

supported by a plurality of pims that 

obiect^ ""^^ receive the 

objects . Th.s provides compatibility with an 

5 increased number of devices wh^^v, 

encounter the objects. ''^^'^ 

Of ti; ^^^^ — preferred feature 

of the present invention, localizers implement a 

10 u eT:r f" ^^^^"^^^ °" -ice 'which ar 

used .n formatting the properties of the objects 
associated with the meeting request. ^ data s ream 
representative of the meeting request is parsed by tL 
mobile device and placed in pre-defined fields in the 
appropriate templates so that the text viewed by the 

15 user of the mobile device more closely conforms to 
local convention. m addition, time zone information 
IS also included in one embodiment. 

BRIEF nPSPPTP^TQ^j OP r.o7.T.TTi.y^^ 

^ ^ ^^^^^^^ illustrating a basic 

2 0 environment of the present invention. 

FIG. 2 is a block diagram of one embodiment of a 
convent onal desktop computer used in conjunction with 

inveTt accordance with the present 

invention. 

„n "k"..' " * Simplified pictorial illustration of 
one embodiment of a mobile device in accordance with 

the present invention. 

FIG. 4 is a simplified block diagram of one 
embodiment of the mobile device shown in FIG. 3 

illu.r'°;- ' ^" architectural block diagram 

Illustrating. one embodiment of portions of the desktop 

FIGS. 3 and 4 to illustrate synchronization of 
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information stored in object stores on the desktop 
computer and the mobile device in accordance with the 
present invention . 

FIG. 6 is an architectural block diagram 
5 illustrating one embodiment of portions of the desktop 
computer shown in FIG. 2 and the mobile device shown 
in FIGS. 3 and 4 to illustrate the generation and 
transmission of a meeting request. 

FIG. 7 is a flow diagram illustrating the 
10 generation of a meeting request in accordance with one 
preferred embodiment of the present invention. 

FIG. 8 is a flow- diagram illustrating the 
handling of responses to a meeting request on the 
mobile device shown in FIGS. 3 and 4 in accordance 
15 with one preferred embodiment of the present 
invention . 

FIG. 9 is a flow diagram illustrating the 
handling of responses to a meeting request on the 
desktop computer shown in FIG. 2 in accordance with 

2 0 one preferred embodiment of the present invention. 

FIG. 10 is a flow diagram illustrating the use of 
a localizer to localize the textual description of a 
meeting request in accordance with one preferred 
embodiment of the present invention. 

25 FIGS- llA and IIB illustrate one embodiment of a 

template used to localize the textual description of a 
meeting request in accordance with the present 
invention - 

DETAILED DESCRIPTION OF THE PREFE RRED EMBODIMENTS 
30 OVERVIEW 

FIG. 1 is a block diagram of a typical system or 
environment 2 in which the present invention operates. 
Environment 2 includes mobile device J and desktop 
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computer 4. pig. i also illustrates that .obile 

tZlT ' k"" separately coupled to 

another .obxle device lo or another desktop computer 

_ Mobile device 3 includes an application program 5 
ana an object store 6. Desktop computer 4 also 
includes an application program 7 and an object store 
8 Mobile device 10 includes an application program 
11 and object store 12. Further, desktop computer 13 
includes an application program 14 and an object store 



Mob.le device 3 is couplable to desktop computer 
4, mobxle device lo or desktop computer 13 by one of a 
plurality of connection mechanisms 9. The operation 
of desktop computers 4 and 13 and the operation of 
mobile devices 3 and lo are preferably similar. 
Therefore, for the sake of simplicity, the present 
oescription proceeds only with respect to mobile 
device 3 and desktop computer 4. 
20 In one preferred embodiment of the present 

invention, application program 7 on desktop 4 is a 
personal information manager (pim) which supports 
electronic mail messaging, scheduling and calendaring 
and an address book containing contact information 

PIM applications are not always integrated For 
instance, some scheduling programs do not contain 
electronic mail features, but interface with whatever 
electronic mail program is provided, and vice versa 
Of course, PIM 7 (whether it be a single application, 
a sxngle integrated application or multiple interfaced 
applications) can be configured to support a wide 
variety of other features, such as task lists and 
personalized address books, to name a few. However 
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for the sake of clarity, only features relating to 
electronic mail messaging, scheduling and calendar 
features, and address book features are discussed in 
detail with respect to the present invention. 
5 Object store 8 is a memory which is configured to 

store a plurality of individual records or objects, 
each comprising a plurality of fields or properties 
related to the above-mentioned features. In one 

preferred embodiment, PIM 7 is a program, such as that 
10 available under the commercial designation Microsoft 
Outlook 97, and object store 8 is configured to store 
objects, each of which has a plurality of properties 
which can be associated with electronic mail 
messaging, scheduling and calendaring, and contact 
15 information. 

For example, some properties included in an 
object associated with electronic mail messaging 
include the sender's name, the recipient's name, text 
messages, an indication of whether attachments are 
20 attached to any given electronic mail message, and 
possibly other similar properties. Also, some 

properties associated with scheduling and calendaring 
include critical time stamp information, date and time 
information, potential attendees, recurrence 

2 5 properties which describe recurrent meetings or 
meeting requests, and a textual description of the 
meeting request. Some properties associated with 
contact information include the proper names, or 
familiar names, of those in the contact list, the 
addresses and telephone numbers of those listed, and 
the fully qualified electronic mail address for those 
in the list. Any number of other properties can also 
be included. Desktop computer 4. ^executes the 
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application . program identified as PIM 7 to maintain 
objects stored in object store 8. 

The application program designated as PIM 5 for 
mobile device 3 is a similar PiM to that stored on 
5 desktop computer 4. Object store 6 on mobile device 3 
is configured to store a plurality of individual 
records or objects, each comprising a plurality of 
fields or properties related to the above-mentioned, 
supported features. As with PIM 7, PiM 5 can also 
10 support a wide variety of other features. However, 
for the sake of clarity, only those features related 
to the present invention are discussed in detail 
herein . 

In one illustrative embodiment, each object in 
15 object store 6 comprises the same set of properties 
stored in object store 8 for related messages, or a 
subset of those properties. In addition, the objects 
stored in object store 6 also preferably include a 
critical change time stamp, properties which indicate 
20 whether potential attendees identified in a meeting 
request have responded, and a global identification of. 
each individual meeting request (discussed in greater 
detail below) . Mobile device 3 executes PIM 5 to 
maintain the objects in object store 6. 
25 In the illustrative embodiment, each object 

stored in object store 8 is also stored in object 
store 6. However, there are actually two instances of 
each object (one in object store 6 and one in object 
store 8) . Thus, when a user changes one instance of 
the object stored in either store 6 or . store 8, the 
second instance of that object in the other of stores 
6 and 8 is preferably updated the next time mobile 
device 3 is connected to • desktop computer 4 so that 



30 



BNSDOCIO: <WO_99a2324A1 J_. 



siiUnnnESiiEEr(iiiii£26) 



wo 99/22324 PCT/US98/22413 



15 

both instances of the same object contain up-to-date 
data. This is referred to as synchronization. 

In order to accomplish synchronization, 
synchronization components run on both mobile device 3 
5 and desktop computer 4. The synchronization 

components communicate with PIMs 5 and 7 on mobile 
device 3 and desktop computer 4 through well defined 
interfaces to manage communication and 

synchronization . 

10" The components of mobile device 3 and desktop 

computer 4 communicate with each other through any 
suitable, and commercially available, communication 
link 9, and using a suitable communications protocol. 
For instance, in one preferred embodiment, mobile 

15 device 3 is connectable to desktop computer 4 with a 
physical cable which communicates using a serial 
communications protocol. Other communication 

mechanisms are also contemplated by the present 
invention, such as infrared (IR) communication, direct 

20 modem communication, remote dial-up networking 
communication, communication through commercially 
available network cards (i.e., using TCP/IP), remote 
access services (RAS) , wireless modem, wireless 
cellular digital packet data (CDPD) , or other suitable 

25 communication mechanisms. 

FIG. 2 and the related discussion are intended to 
provide a brief, general description of a suitable 
desktop computer 4 in which portions of the invention 
may be implemented. Although not required, the 

30 invention will be described, at least in part, in the 
general context of computer-executable instructions, 
such as program modules, being executed by a personal 
computer 4 or mobile device 3. Generally, program 
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modules include routine programs, objects, components, 
data structures, etc. that perform particular tasks or 
implement particular abstract data types. Moreover 
those skilled in the art will appreciate that desktop 
computer 4 may be implemented with other computer 
system configurations, including multiprocessor 
systems, microprocessor-based or programmable consumer 
electronics, network PCs, minicomputers, mainframe 
computers, and the like. The invention may also be 
practiced in distributed computing environments where 
tasks are performed by remote processing devices that 
are linked through a communications network. m a 
distributed computing environment, program modules may 
be located in both local and remote memory storage 
15 devices. Examples of distributed programs include 
those available under the commercial designations 
Exchange, Schedule-, and MS Mail, all available from 
Microsoft Corporation. 

With reference to FIG. 2, an exemplary system for 
20 implementing desktop computer 4 includes a general 
purpose computing device in the form of a conventional 
personal computer 4, including processing unit 21 a 
system memory 22, and a system bus 23 that couples 
various system components including the system memory 
25 to the processing unit 21. The system bus 23 may be 
any of several types of bus structures including a 
memory bus or memory controller, a peripheral bus, and 
a local bus using any of a variety of bus 
architectures. The system memory includes read only 
memory (ROM) 24 and random access memory (RAM) 25. 

A basic input/output system (BIOS) 26, containing 
tne basic routine that helps to transfer information ' 
between elements within the- desktop computer 4, such 
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as during start-up, is stored in EEPROM which is part 
of ROM 24 . The desktop computer 4 further preferably 
includes a hard disk drive 27 for reading from and 
writing to a hard disk (not shown) , a magnetic disk 
5 drive 28 for reading from or writing to removable 
magnetic disk 29, and an optical disk drive 3 0 for 
reading from or writing to a removable optical disk 31 
such as a CD ROM or other optical media. The hard 
disk drive 27, magnetic disk drive 28, and optical 

10 disk drive 3 0 are connected to the system bus 23 by a 
hard disk drive interface 32, magnetic disk drive 
interface 33, and an optical drive interface 34, 
respectively. The drives and the associated computer- 
readable media provide nonvolatile storage of computer 

15 readable instructions, data structures, program 
modules and other data for the desktop computer 4 . 

Although the exemplary environment described 
herein employs a hard disk, a removable magnetic disk 
2S and a removable optical disk 31, it should be 

2 0 appreciated by those skilled in the art that other 
types of computer readable media which can store data 
that is accessible by a computer, such as magnetic 
cassettes, flash memory cards, digital video disks 
(DVDs) , Bernoulli cartridges, random access memories 

2 5 (RAMs) , read only memory (ROM) , and the like, may also 

be used in the exemplary operating environment. 

A number of program modules may be stored on the 
hard disk, magnetic disk 29, optical disk 31, ROM 24 
or RAM 25, including an operating system 35, one or 

3 0 more application programs 36 (which include PIMs 7) , 

other program modules 37, and program data 38. A user 
may enter commands and information into the desktop 
computer 4 through input devices such a'S a keyboard 
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40, pointing device 42 and microphone 62. Other input 
devices (not shown) may include a joystick, game pad, 
satellite dish, scanner, cr the like. These and other 
input devices are often connected to the processing 
unit 21 through a serial port interface 4 6 that is 
coupled to the system bus 23, but may be connected by 
other interfaces, such as a sound card, a parallel 
port, a game port or a universal serial bus (USB) . A 
monitor 47 or other type of display device is also 
connected to the system bus 23 via an interface, such 
as a video adapter 48. In addition to the monitor 47, 
desktop computers may typically include other 
peripheral output devices such as speaker 45 and 
printers. 

15 The desktop computer 4 may operate in a networked 

environment using logic connections to one or more 
remote computers (other than mobile device 3), such as 
a remote computer 49. The remote computer 4 9 may be 
another personal computer, a server, a router, a 
20 network PC, a peer device or other network node, and 
typically includes many or. all of the elements 
described above relative to desktop computer 4, 
although only a memory storage device 50 has been 
illustrated in FIG. 2. The logic connections depicted 
25 in FIG. 2 include a local area network (LAN) 5i and a 
wide area network (WAN) 52. Such networking 

environments are commonplace in offices, enterprise- 
wide computer network intranets and the Internet. 

When used in a LAN networking environment, the 
3 0 desktop computer 4 is connected to the local area 
network 51 through a network interface or adapter 53. 

When used in a WAN networking environment, the 
desktop computer 4 typically includes ar modem 54 or 
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other means for establishing communications over the 
wide area network 52, such as the Internet. The modem 
54, which may be internal or external, is connected to 
the system bus 23 via the serial port interface 46. 
5 In a network environment, program modules depicted 
relative to desktop computer 4, or portions thereof, 
may be stored in the remote memory storage devices . 
It will be appreciated that the network connections 
shown are exemplary and other means of establishing a 

10 communications link between the computers may be used. 

Desktop computer 4 runs operating system 3 5 that 
is typically stored in non-volatile memory 24 and 
executes on the processor 21, One suitable operating 
system is a Windows brand operating system sold by 

15 Microsoft Corporation, such as WINDOWS 95 or WINDOWS 
NT, operating systems, other derivative versions of 
WINDOWS brand operating systems, or another suitable 
operating system. Other suitable operating systems 
include systems such as the Macintosh OS sold from 

2 0 Apple Corporation, and the OS/2 Presentation Manager 
sold by International Business Machines (IBM) of 
Armonk, New York. PIM 7 is preferably stored in 
program module 37, in volatile memory or non-volatile 
memory, or can be loaded into any of the components 

25 shown in FIG. 2 from a floppy diskette 29, CDROM drive 
31, downloaded from a network via network adapter 53, 
or loaded using another suitable mechanism. 

A dynamically linked library (DLL) , comprising a 
plurality of executable functions is associated with 
30 PIM 7 for execution by processor 21. Interprocessor 
and intercomponent calls are facilitated using the 
component object model (COM) as is common in programs 
written for MICROSOFT WINDOWS brand operating systems. 
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Briefly, when using COM, a software component such as 
a DLL has a number of interfaces. Each interface 
exposes a plurality of methods, which can be called 
individually to utilize different services offered by 
5 the software component. In addition, interfaces are 
provided such that methods or functions can be called 
from other software components which optionally 
receive and return one or more parameter arguments. 

In general, the DLL associated with PIM 7 is 

10 designed specifically to work in conjunction with PIM 
7 and to expose desktop synchronization interfaces 
that function as described in more detail in the 
above- referenced co-pending U.S. patent application 
according to a synchronization protocol. The DLL, in 

15 turn, calls interfaces exposed by PIM 7 in order to 
access data representing individual properties of 
objects maintained in object store 8. Object store 8, 
of course, can reside in any one of the suitable 
memory components described with respect to FIG. 2. 

20 FIG. 3 is a pictorial illustration of one 

preferred embodiment of a mobile device 3 which can be 
used in accordance with the present invention. Mobile 
device 3, in one preferred embodiment, is a desktop 
assistant sold under the designation H/PC and being 

25 based on, for example, the WINDOWS CE BRAND operating 
system provided by Microsoft Corporation. In one 
preferred embodiment, mobile device 3 is housed in a 
housing which fits comfortably in the hand of a 
typical user. Mobile device 3 has some components 

30 which are similar to those of desktop computer 4. For 
instance, in one preferred embodiment, mobile device 3 
includes a miniaturized keyboard 82, display 84, and 
stylus 86. Of course, other configurations, such as 
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without keyboards, can also be used. 

In the embodiment shown in FIG. 3, display 84 is 
a liquid crystal display (LCD) which uses a contact - 
sensitive display screen in conjunction with stylus 
5 86 . Stylus 86 is used to press or contact the display 
84 at designated coordinates to accomplish certain 
user input functions. Of course, other user input 
configurations can be used as well. For example, user 
input mechanisms could be included such as a keypad, a 
10 track ball, and other various types of miniaturized 
keyboards, or the like. In addition, mobile device 3 
may not be embodied as the H/PC brand of digital 
assistant, but could also be implemented as another 
type of personal digital assistant (PDA) , another 
15 personal organizer, a palm top computer, or a similar 
computerized notepad device. 

FIG. 4 is a more detailed block diagram of mobile 
device 3. Mobile device 3 preferably includes 

microprocessor 88, memory 90, input /output (I/O) 
2 0 components 92 (which include keyboard 82 and touch 
sensitive screen 84), optional expansion slots 93 
(which can be used for plugging in such things as PC 
cards, compact flash memory, etc.) and serial 
interface 94. In the illustrative embodiment, these 
25 components of mobile device 3 are coupled for 
communication with one another over a suitable bus 96. 

In the illustrative embodiment, memory 90 is 
implemented as non-volatile electronic memory such as 
a random access memory (RAM) with a battery back-up 
30 module (not shown) such that . information stored in 
memory 90 is not lost when the general power to mobile 
device 30 is shut down. A portion of memory 90 is 
preferably allocated as addressable memory for program 
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execution, „hiie another portion of „e^ry .0 is 
preferably used to simulate storage on a disk Trive 

Memory 9o includes operating system 96 and 
application ,or Pl„, s. Operating system .a. during 
operation, is preferably loaded Hnt-^ ^ uring 

ij-Ly ±oaaed into, and executed bv 
processor 88 from memory 90 Ooerar-in^ . 

operating system 98, in 
one preferred embodiment is rh« tt- ^ 

-^•"ciit., IS the Windows CE brand 
operating system tv,« orana 

g ystem. The operating system 98 is 

preferably designed for mobile devices and imr.T . . 
j_^_T- = r,« jr ^ -sviues, ana implements 

aatabase features which can be utdH,o^ 

utilized by Pim 5 

nrough a set of exposed application programming 
interfaces and methods. The objects in object store e 
«e preferably maintained by PI„ 5 and operating 
system ss, at least partially in response to calls to 
the exposed application program interfaces and 
methods. 

It should be noted that pim 5 is not necessarily 
designed to be entirely compatible with PiM 7 which 
executes on desktop computer 4. For instance, there 
20 may not be a precise one-to-one matching between the 
. properties of specific object types. Some properties 
supported by the electronic mail messaging features of 
PIM 5 .,ay have no corresponding features in PIM 7 on 
aesktop computer 4, and vise versa. 

OBJECT SYNCHRONIZATION 
Object synchronization is described here 
briefly, to assist in understanding the present 
invention. i^j.cfi:>enx: 

illu.r'';- ' architectural block diagram 

illustrating one preferred embodiment of architectural 
components of mobile device 3 and desktop computer 4 
Which are used in synchronizing objects stored in ' 
object store 6 on mobile device 3 and object store 8 
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on desktop computer 4 . It should be noted that the 
synchronization architecture illustrated in FIG. 5 is 
but one preferred embodiment and others could be used 
as well. Further, the synchronization operation can 
5 be carried out between any two coupled stores (such as 
those on any combination of pairs of computers 4 and 
13, and mobile devices 3 and 10) . All that is 
required is a synchronization manager component, as 
described below, which directs synchronization of the 

10 two coupled stores. The synchronization manager can 
reside on either device, or both, or on a third 
computer coupled to the two stores. However, for the 
sake of simplicity, only the embodiment in which 
desktop computer 4 is coupled to mobile device 3 is 

15 described herein. Also, the present synchronization 
protocol is but one preferred embodiment, as another 
suitable protocol could be implemented on top of 
standard electronic mail protocols. 

In addition to PIM 5 and object store 6, mobile 

2 0 device 3 includes synchronization module 97 which, in 

turn, includes interface component 100, and 
synchronization manager 102. Mobile device 3 also 
includes communications component 94, remote 
application programming interface (RAPI) server 116, 
25 and electronic mail messaging transports 132, 134 and 
136 . 

Desktop computer 4 includes, in addition to PIM 7 
and object store 8, synchronization module 99 which, 
in turn, includes interface component 108, 

3 0 synchronization manager 110, reference store 112, and 

RAPI component 114. Desktop computer 4 also includes 
communications component 115. 

Generally, in the embodiment illustr-ated in FIG. 
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5, synchronization manager lio executes on desktop 
computer 4 and orchestrates synchronization between 
objects in object store 6 in handheld device 3, and 
objects in object store 8 in desktop computer 4. 
Synchronization manager no also maintains reference 
store 112 apart from desktop object store 8 as is 
described in greater detail below. Synchronization 
manager 110 implements the synchronization protocol to 
allow a comparison between corresponding objects 
stored in object store 6 in mobile device 3 and object 
store 8 in desktop computer 4, to receive objects from 
object store 8, and to update objects in object store 
8. The synchronization protocol also facilitates the 
retrieval of objects stored in object store 6 in 
15 mobile device 3 through synchronization interface 
component 100 and synchronization manager 102, as well 
as communications component 94 . 

On the side of mobile device 3, the 
synchronization interface component 100 exposes 
20 application programming interfaces which 

^y"'^.^''^^^^^^^^" manager 102 calls . to read . and store 
objects and object properties on object store 6. In 
general, the application programming interfaces allow 
the creation of databases for different types of 
25 objects, and allow application programs to write and 
read property names and values to and from respective 
objects within object store 6. 

As discussed with respect to FIG. 1, PIM 5 
executes on mobile device 3 and maintains object store 
30 6. PIM 7 executes on desktop computer 4 and maintains 
object store 8. There are many different ways which 
PIMs 5 and 7 can store objects in object stores 6 and 
8. However, in a preferred embodiment PIMs 5 and 7 
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create a distinct database for each object type. For 
example, different databases are created for meetings, 
contacts, tasks, electronic mail messages, etc, A 
predefined set of properties is supported for each 
5 object type, and each of the databases is assigned a 
name by the application program that creates it. 

In an alternative embodiment, the application 
programs in PIMs 5 and 7 may use a single database for 
all object types, with the first property of each 
10 object defining the type of object. In any case, 
objects are uniquely identified within mobile device 3 
and desktop computer 4 by object identifiers which are 
independent of the names assigned by the application 
programs creating the object. 
15 Synchronization manager 110 is not necessarily 

closely associated with PIM 7. Rather, it is an 
independent component which synchronizes objects from 
any application program that supports the appropriate 
desktop synchronization interfaces. The specific 

2 0 synchronization interfaces are described in greater 
detail in the co-pending patent application 
incorporated above. Communication components 94 and 
115 implement serial communications between the 
computers using suitable link 9. 
2 5 Synchronization manager 110 communicates with PIM 

7 and accesses object store 8 through synchronization 
interface component 108. Synchronization interface 
component 108 corresponds generally to a DLL discussed 
with respect to FIG. 2 above, and exposes one or more 
30 application program interfaces and methods. 

The interfaces and methods are described in 
greater detail in the co-pending patent application 
which is incorporated above by referenc'e. Of these 
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interfaces, one of note is preferably of the form 
known as messaging application program interfaces 
(MAPI) developed and published by the Microsoft 
corporation for Windows brand operating system 
platforms, but other suitable interfaces can be used 
as well. In one preferred embodiment, the MAPI 
exposed by component 108 is a C-language application 
programming interface which allows programmable access 
to features of an electronic mail messaging program 
known as MS Mail also commercially available from the 
Microsoft Corporation. m another preferred 

embodiment, the MAPI exposed by component 108 is a 
component object model based (COM -based) set of 
interfaces which is sometimes referred to as extended 
15 MAPI and includes a set of automation interfaces to 
messaging systems, for use in Visual Basic and the 
like. However, synchronization interface component 
108 and the associated application program interfaces 
and methods can be any suitable synchronization 
20 interface components designed for any particular 
application in PIM 7. Because the application program . 
interfaces are preferably standardized, they allow 
synchronization manager no to access and synchronize 
any number of different desktop PiMs, as long as the 
25 required interface methods are implemented for each 
PIM. 

Reference store 112 provides a mapping between 
instances of objects stored in object store 6 on 
mobile device 3 and objects stored in object store 8 
30 on desktop computer 4. since the same object 
identifiers are not used by PIM 5 to identify objects 
on object store 6 as are used by PIM 7 to identify 
objects in object store 8, this mapping is -required. 
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Synchronization manager 110 maintains reference 
store 112 so that reference store 112 contains the 
identifying data segments corresponding respectively 
to a plurality of object instances in object store 8 
5 on desktop computer 4 that are to be synchronized with 
instances of the same object in object store 6 on 
mobile device 3 . The identifying data segments are 
updated each time corresponding object instances have 
been synchroni zed . 

10 The exact composition of an identifying data 

segment which is used to identify the particular 
object instances are assignable by the developer of 
the desktop synchronization interface component 108, 
and are then handled and stored by synchronization 

15 manager 110. The identifying data segments preferably 
include some sort of time stamp information which can 
be compared to determine whether an object has changed 
since the identifying data segment was last recorded 
in reference store 112 . 

2 0 In addition to maintaining a plurality of 

identifying data segments, synchronization manager 110 
also maintains a list of object identifiers 
corresponding to objects maintained in object store 6. 
These identifiers are provided to synchronization 

25 manager 110 whenever a new object is added to object 

store 6 on mobile device 3 . 

SYNCHRONIZATION PROTOCOL 

The exact protocol by which full synchronization 
is accomplished in accordance with one embodiment of 
30 the present system is described here briefly. The 
brief discussion of that protocol is helpful in 
understanding of the present invention. In order to 
synchronize objects, synchronization manager 110 first 
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creates two lists of handles which refer to particular 
objects. The term "handle" refers to a number or 
other identifier that can be used to uniquely identify 
an object and to access the object. Generally, a 
handle is valid for a particular time period or 
session, such as during the time when an object has 
been "opened." if the same object is opened again, 
its handle may be different. 

The first list of handles is obtained from 
reference store 112 and is indicative of objects which 
have been synchronized in the past and are identified 
in reference store 112. The second list of handles is 
a list which identifies the objects stored on object 
store 8. The two lists of handles are compared 
15 against one another to determine whether the same 
objects are stored in reference store 112 and object 
Store 8 . 



If an object is identified in reference store 
112, but not in object store 8, that particular object 
has been deleted from the desktop 4 since the last 
synchronization. On the other hand, if an object is 
identified in object store 8, but it does not appear 
m reference store 112, then it has been added to the 
desktop since the last synchronization. m either 
25 case, synchronization manager lio determines how to 
handle the object. In one preferred embodiment, those 
objects which have been deleted from desktop object 
store 8 are also deleted from reference store 112. 
Further, those which have been added to object store 8 
are also added to reference store 112. 

Synchronization manager 110 then determines 
whether any of the objects stored in object store 8 
have been modified at the desktop sin'ce the last 
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synchronization. In other words, if handles 

corresponding to the same object appear in both object 
store 8 and reference store 112, but they are not 
identical (such as the time stamp, a revision number, 
5 or another suitable identifying segment is not the 
same) that indicates that the object in object store 8 
has been modified since the last synchronization. 

Synchronization manager 110 then determines 
whether any objects stored in object store 6 on mobile 

10 device 3 have been added or modified since the last 
synchronization. To determine whether an object has 
been added to object store 6, synchronization manager 
110 compares the list of objects in reference store 
112 (which reflects all objects at the last 

15 synchronization) with a list of objects on object 
store 6 maintained by synchronization manager 102. To 
determine whether an existing object has been 
modified, synchronization manager 102 is configured to 
maintain a status bit associated with each object 

2 0 stored in object store 6. The status bit reflects 

whether the particular object associated with that bit 
has been changed since the last synchronization. If 
so, synchronization manager 102 notifies 

synchronization manager 110 of that change if device 3 
25 • is then coupled to desktop computer 4, or simply logs 
the status bit and sends it to synchronization manager 
110 the next time device 3 is coupled to desktop 
computer 4 . 

It should be noted that none of these procedures 

3 0 require either synchronization manager 110 or 

synchronization manager 102 to be aware of the 
particular nature or format of. the identifying data 
segments or of the .objects to which they -correspond. 
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Rather, interface components lOO and 108 are called 
upon for all actions that depend upon the actual 
content of the identifying data segments, and the 
content of the objects. it is up to the designer of 
5 those interfaces to define a format for the 
Identifying data segments that allows the interfaces 
to perform their required functions. 

Once the changes, additions and" deletions are 
determined by synchronization manager no, the items 
10 are synchronized. m order to do this, 

synchronization manager no forms a list of objects 
which have been changed on either object store 8 or 
object store 6 and simply calls upon the respective 
synchronization interface components to update the 
15 outdated object. if the same object has been modified 
both on mobile device 3 and desktop computer 4, a 
conflict arises. Synchronization manager no resolves 
the conflicts by either prompting the user, or 
referencing profile information entered by the user 
2 0 during a set-up procedure which dictates which device 
the user wants to take precedence over the other, and 
in which instances. The process of setting up profile 
information is described in greater detail in the 
above- identification patent applications. 
25 Where an object has either been created at the 

desktop computer 4 or in the mobile device 3, that 
object needs to be exchanged with the other device. 
In the instance where mobile device 3 needs to obtain 
a new object from desktop computer 4, synchronization 
manager no calls an interface method known as "Set- 
Up" which specifies a handle for the object to be 
obtained from object store 8 in desktop computer 4 and 
transferred to object store 6 in mobile, device 3. 
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Once the handle is obtained, the method known as 
"GetPacket" is called repeatedly to retrieve a data 
stream which represents the object, and which is 
formatted by interface component 108. Synchronization 
5 manager 110 simply treats the data as a data stream 
which is retrieved and sent over link 9 to 
synchronization manager 102, and eventually to object 
store 6 . The appropriate synchronization interface 
component 100 parses the data stream in order to 

10 identify certain property values associated with 
properties corresponding to the object. Those 
properties are then stored in the object store 6. 

Finally, synchronization manager 110 updates the 
identifying data segments associated with either 

15 synchronized or exchanged objects and stores the 
updated data segments in reference store 112 . 

It is worth noting that the architecture 
described herein provides synchronization of objects 
associated with electronic mail messages, meetings or 

2 0 appointments, and contacts information, as well as 

other objects maintained by PIMs 5 and 7. Thus, using 
the above synchronization protocol, objects associated 
with these features are synchronized during the 
synchronization process. Synchronization manager 110 
25 detects any new objects in object store 8 which 
represent new electronic mail messages, meetings or 
appointments or contact information and causes those 
objects to be transferred to object store 6 on mobile 
device 3 for attention by the user of mobile device 3. 

3 0 Further, if the user composes an electronic mail 

message or schedules a meeting (and therefore creates 
a meeting object and an electronic mail meeting 
request object) or enters contact information on 
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.obile device 3 using an appropriate application in 
PIM 5, the objects associated with those items are 
stored as new objects in object store 6. During 
synchronization, those new objects are transferred to 
desktop computer 4 and object store 8. 

MEETING REQUESTS 
FIG. 6 is an architectural block diagram 
Illustrating one preferred embodiment of a mechanism 
by which meeting requests are generated. Mobile 
devxce 3 and desktop computer 4 are shown coupled to 
one another, as shown in FIG. 5. However, FIG. 6 also 
.llustrares that mobile device 3 and desktop computer 
4 can be coupled to a wide area network 138 which can 
include simply another mobile device, another desktop 
computer, LAN 51 (shown in FIG. 2), WAN 52 (shown in 
FIG. 2), or any other suitable network. 

Similar items to those shown in FIG 5 are 
similarly numbered. However, in FIG. 6, pims 5 and 7 
are shown in greater detail. FIG. 6 illustrates that 
xn one preferred embodiment, pim 5 includes an 
electronic mail application 140, a calendar and 
scheduling application 142, and an abridged address 
book 144. Also, while each of the applications may 
have designated application programming interfaces, 
only a single API component 146 is shown in FIG. 6, 
for the sake of simplicity. 

FIG. 6 further illustrates that object store 6 
preferably interfaces with applications 140, 142 and 
144 through its own set of application programming 
interfaces 148. Thus, applications 140, 142 and 144 
maintain object store 6 by calling methods exposed by 
application programming interfaces 148 associated with 
object store 6. In addition, communication component 
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94 and sync component 9 9 communicate with application 
programs 140, 142 and 144 by calling methods exposed 
by application programming interfaces 146. 

PIM 7 in desktop computer 4 has also been 
5 illustrated as a more detail block diagram. In one 
preferred embodiment, PIM 7 includes electronic mail 
application program 150, scheduling and calendaring 
program 152 and full address book program 154 . While 
each of the application programs 150, 152 and 154 may 

10 have an associated set of application programming 
interfaces, only a single application programming 
interface component 156 is illustrated in FIG. 6, for 
the sake of simplicity. 

FIG. 6 further illustrates that, in one preferred 

15 embodiment, object store 8 is associated with its own 
set of application programming interfaces 158 (which 
may also be the same as API 156, preferably MAPI, or- 
which may be separate therefrom) . Thus, application 
programs 150, 152 and 154 call methods exposed by 

2 0 application programming interfaces 158 to maintain, 

and interact with, object store 8. In addition, 
communications component 115 calls methods exposed by 
application programming interfaces 156 to interact 
with application programs 150, 152 and 154. 
25 FIG. 6 shows that desktop computer 4 preferably 

includes electronic mail transport 160. Electronic 
mail transport 160 is preferably a commercially 
available electronic mail transport, such as a SMTP 
transport. However, it should be noted that desktop 

3 0 computer 4 can include any suitable transport, or 

combination of transports. 

FIG. 7 is a flow diagram illustrating the 
creation of a meeting request on mobile device 3. The 
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15 



following description will proceed with reference to 
FIGS. 6 and 7. 

In order to create a meeting request from mobile 
aevice 3, the user first enters meeting request 
5 information through a suitable user interface. m one 
preferred embodiment, the user opens the scheduling 
application program 142 which causes a suitable user 
interface to be displayed on screen 84. Using stylus 
86, and possibly keypad 82 (or any other suitable 
10 input mechanism), the user enters appropriate 
information to request a meeting. Such information 
will typically include the date and time of the 
meeting, the requested attendees (which may be entered 
by using a fully qualified electronic mail address, or 
by entering a familiar name, or selected from entries 
in a contacts database which have a non-empty 
electronic mail address field), the subject matter of 
the meeting, an indication of whether the meeting is 
recurring or a single event, possibly the location of 
the meeting, and so on. Scheduling application 142 
creates an object representative of. the meeting 
request . 

This information is used to create a meeting 
object and enter that object in the store associated 

25 with the calendar on mobile device 3. As a result of 
the creation of the meeting object, an electronic mail 
meeting request object is also created. it should 
also be noted that subsequent critical modifications 
to the meeting object will also cause updated 

30 electronic mail meeting request objects to be created 
and transmitted as well. 

In a preferred embodiment, a selection has 
already been made which specifies a transport by which 
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any electronic mail meeting request objects are to be 
sent. Alternatively, the transport to be used can be 
implicit in the full electronic mail address, itself. 
For example, it can be specified that any of 
5 transports 132-13 6 are to be used, when mobile device 
3 is to transmit the meeting request itself . In 
addition, a selection has also preferably already been 
made to specify certain options which are to be used 
in the sync protocol discussed above. For example, if 
10 an inbox synchronization option is enabled, the 
electronic mail meeting request objects will be 
synchronized to the outbox of desktop computer 4 . 
Also, if a calendar synchronization option is enabled, 
the meeting object will be synchronized to the 
15 calendar of desktop computer 4. Desktop computer 4 
then preferably transmits the electronic mail meeting 
request object synchronized to its outbox. 

The receipt of the meeting request information 
from the user, and the creation of a meeting object 
20 representative of the meeting . and an electronic mail 
meeting request object are indicated by blocks 162 and 
164 in FIG. 7. 

Next, the critical time stamp is added to the 
objects (as indicated by block 165) and scheduling 
25 application 142 assigns a global object identification 
tag to the meeting object created. The global object 
identification tag is a tag, such as a number, which 
uniquely identifies the object representative of the 
meeting request to mobile device 3, to desktop 
3 0 computer 4, and to all other devices which may 
encounter that object. The global identification tag 
is carried with, the electronic mail meeting request 
object when it is transmitted, and remains with the 
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object on other devices. This is indicated by block 

166. 

Because the electronic mail meeting request 
object must be transmitted to another device 
scheduling application 142 calls methods in API' 146 
which manipulate electronic mail program 14 0 to 
retrieve a fully qualified electronic mail address for 
all of the potential attendees who are to receive the 
meeting request. m one preferred embodiment, 

scheduling application 142 obtains the fully qualified 
address directly from an address book. m another 
embodiment, mobile device 3 includes abridged address 
book program 144. m a preferred embodiment, abridged 
address book program 144 is implemented as a contacts 
feature provided by Microsoft Outlook 97. The 
abridged address book contains proper names, familiar 
names, addresses, telephone numbers, and fully 
qualified electronic mail addresses for people that 
the user has chosen to add to the abridged address 
book. Those people will likely be people who receive 
a significant number of electronic mail messages from 
the user of mobile device 3. Therefore, that 
information likely contains the fully qualified 
electronic mail addresses for the potential attendees 
of the meeting request. In addition, if the address 
:ls not fully qualified, the synchronization component 
97 on desktop 4 attempts to resolve the name on the 
desktop prior to sending the electronic mail 
transmission . 

Thus, either electronic mail application 140 or 
scheduling application 142 call methods in API 146 
which cause abridged address book program 144 to 
retrieve the fully qualified electronic ™ail address 
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for the familiar names entered by the user as 
potential attendees. This significantly alleviates 
memory overhead which would otherwise be required, for 
instance, if the user was required to download a full 
5 address book from desktop computer 4 in order to send 
an electronic mail message or a meeting request. This 
is indicated by block 168. In another preferred 
embodiment, the functionality associated with block 
168 is performed at block 162, as soon as the user 

10 inputs the appropriate information. 

Also, the transport option has preferably 
already been chosen which indicates the particular 
transport by which the electronic mail messages are to 
be transmitted. Those transports can be any of 

15 transports 13 2-136 on mobile device 3 or through 
synchronization with desktop computer 4, using one of 
its transports. Based on the option which has been 
chosen, the electronic mail meeting request object is 
transmitted through the appropriate transport and, 

20 once transmitted, is removed from the outbox of mobile 
device 3 . 

If the electronic mail meeting request object is 
to be sent directly from one of the transports on 
mobile device 3, the appropriate transport formats the 

25 meeting request for transmission . In a preferred 
embodiment, the particular properties which scheduling 
application program 142 attributes to an electronic 
mail meeting request object representative of a 
meeting request are compatible with multiple other 

30 PIMs. Therefore, these properties may be a subset or 
a superset, of all of the properties recognized by the 
multiple PIMs such that the object can be entertained 
and appropriately handled by those PIMs. • Appendix A, 
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which is attached hereto and forms a part of this 
document, is a list of message properties by which the 
MICROSOFT SCHEDULE, brand scheduling program defines 
objects associated with meeting requests. These 
5 properties notably include revised recurring 
notification properties which are backward compatible 
with other versions of MICROSOFT SCHEDULE+ scheduling 
software. For instance, in the embodiment described 
in Appendix A, recurring notifications which are used 

10 to define recurring meetings are formatted as a 
superset of single -instance notifications. in this 
way, prior versions of the MICROSOFT SCHEDULE+ 
scheduling software will be provided with well formed 
meeting notifications, even for recurring meetings. 

15 In the preferred embodiment, scheduling program 

142 then calls methods exposed by API 14 6 related to 
electronic mail application program 140. The 
electronic mail message which contains the electronic 
mail meeting request object is formulated into one of 

2 0 a predetermined number of classes by electronic mail 

application 140. The receiving scheduler program of 
- the potential attendee differentiates between the type 
of meeting notification based on the mail message 
class. For example, in one preferred embodiment, mail 
25 message classifications exist for a meeting 
cancellation notice from the originator, a meeting 
request from the originator, a meeting acceptance from 
the attendee, a meeting declined from the attendee and 
a meeting tentatively accepted from the attendee. 

3 0 Thus, this is preferably included along with the 

object when the transport formats the electronic mail 
meeting request object for transmission. The meeting 
request is transmitted, through communications 
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component 94 to the designated transport 132, 134 or 
136 which, in turn, formats and transmits the message 
to network 138. 

The formatting and transmission of the electronic 
5 mail meeting request object from a transport on mobile 
device 3- is indicated by blocks 172 and 174 in FIG. 7, 

After the electronic mail meeting request object 
is sent, it is removed from the outbox of mobile 
device 3 to indicate that the message has been sent . 
10 This is indicated by block 190. Upon next being 
coupled to desktop computer 4, the meeting object is 
synchronized to the store containing the calendar on 
desktop computer 4. Preferably, the PIMs also provide 
a feature which can be utilized to prevent the PIM 
15 from creating and sending an electronic mail meeting 
request object simply because the meeting object has 
been synchronized to the calendar on the desktop. The 
feature may simply be to only create electronic mail 
meeting request objects for meeting requests created 
20 on the desktop. This feature is implemented to 
further address the problem of duplicate messaging. 

If the transport option has been chosen to send 
the electronic mail meeting request object using the 
synchronization protocol and a mail transport on 
25 desktop computer 4, processing is substantially the 
same, except that the electronic mail meeting request 
object is synchronized to the outbox of desktop 
computer 4 (as indicated by block 173) . Mobile device 
3 simply waits until it is coupled to desktop computer 
3 0 4 before any further action is taken with respect to 
that meeting request. Upon coupling of mobile device 3 
to desktop computer 4 , the synchronization protocol 
described above is executed. During the 
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synchronization process, the meeting object 
synchronized to the calendar on the desktop computer I 
and the electronic mail meeting request object is then 
synchronized to the outbox of desktop computer 4 
through synchronization components 97 and 99 Upon 
receiving the electronic mail meeting request object 
indicative of the meeting request, electronic mail 
application program 150 recognizes that the meeting 
request needs to be transmitted. Electronic mail 
application program 150 calls the necessary methods 
exposed by API 158 to have the appropriate object 
transported, through communications component lis and 
transport 160, to network 138. This is again 

indicated by blocks 172, 173, 174 and 190. 

woJ^th noting that, in one 
alternatively preferred embodiment, the meeting 
request need not be entirely formatted on mobile 
device 3. Instead, the data representing the 

electronic mail meeting request object can simply be 
20 stored and transferred during synchronization to 
desktop computer 4 where it is. f ully . formatted .. For 
instance, in one preferred embodiment, mobile device 3 
does not store the particular transport to be used by 
desktop computer 4 in sending the meeting request. 
Since this information is not stored by mobile device 
3, it is not synchronized with desktop computer 4. 
Instead, electronic mail application program 150 on 
desktop computer 4 (prior to sending the meeting 
request) calls the necessary methods through API 156 
to have full address book 154 retrieve the transport 
associated with each of the potential attendees 
Identified by the user. That information is then used 
by electronic mail application program 150 in choosing 
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the appropriate transport 160 with which to transmit 
the electronic mail meeting request object. In this 
way, additional memory capacity need not be consumed 
on mobile device 3 to store such transport 
5 information. This is indicated by block 188. 

In any case, once electronic mail application 
program 150 causes the electronic mail meeting request 
object to be transmitted to network 138, it is removed 
from the outbox . This is indicated by block 190. 

10 After the electronic mail meeting request object 

has been sent it is determined whether any other 
meeting requests were synchronized with desktop 
computer 4 during the last synchronization process. 
If not, normal processing continues. If so, 

15 processing reverts back to block 172 wherein 
electronic mail application program 150 calls the 
necessary APIs to send the object. This is indicated 
by block 192. 

FIG. 8 is a flow diagram illustrating one 

2 0 preferred embodiment of how mobile device 3 handles 
responses to the meeting requests transmitted in 
accordance with FIG. 7. In the preferred embodiment, 
the addressee for responses to meeting requests is the 
meeting originator. Both senders and recipients of 

2 5 the meeting requests can be arranged properly for 

delegate handling. The publicly available MAPI 

specification fully discloses how to interpret such 
properties . 

Thus, the recipient of the meeting request is 

3 0 provided with a suitable user interface to indicate a 

response. The response is addressed to the meeting 
originator, or another proper delegate. The response 
is then transferred by the device which the recipient 



siiBsnnnESiiEEr(iHii£26) 

BNSDOCID: <WO 9922324A1 I > 



wo 99/22324 

PCT/US98/22413 



42 



10 



15 



IS operating on and is received through one of 
transports 132, 134 or 136, or through communications 
component 94 on mobile device 3. This is indicated by 
block 194 in FIG. 8. 

Upon receiving the response, scheduling 
application program 142 correlates the response to the 
meeting object which was formed by scheduling 
application program 142 when the user created the 
request, and which is stored in object store 6. This 
correlation is performed by using the unique global 
Identification number which uniquely identifies that 
meeting request to all devices which may encounter it. 
This is indicated by block 196. 

The critical time stamp information is then 
checked to determine whether the response corresponds 
to the latest meeting object. The response preferably 
actually contains two time stamps. The first is the 
recipient's opinion of the originator's critical time 
stamp. The second is a time stamp assigned by the 
20 recipient. The first is checked to determined whether 
It is the same as the originator • s time stamp. if so, 
the response is considered to be in date. If not, the 
response is rejected or ignored as an out-of-date 
response. The second must be equal to or greater than 
25 any previously recorded time stamp from this 
particular recipient for the response to be in date. 
If not, the response is rejected or ignored as out-of- 
date. This is indicated by block 197. 

It should be noted that in the preferred 
embodiment, the time stamps are always moving forward 
Thus, even if the user resets the clock sufficiently 
into the past, any subsequent time stamp is always the 
later of a current clock time and the last time stamp 
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plus one second. 

Scheduling application program 142 then calls the 
necessary methods exposed by API 14 8 in order to 
update the attendee status associated with the 
5 request. This is updated based on the particular 
response received from the attendee. This is 

indicated by block 198. 

Mobile device 3 then simply waits to be connected 
to desktop computer 4. Once it is connected, the 

10 updated objects (containing the updated attendee 
status property) are synchronized to the instance of 
that object stored in object store 8. This is 
accomplished utilizing the synchronization protocol 
discussed above. This is indicated by blocks 200 and 

15 202. The meeting object is then available to 
scheduling application program 152 and desktop 
computer 4 to be displayed on the user's calendar at 
desktop computer 4 for user observation and 
interaction. 

2 0 FIG. 9 is a flow diagram which illustrates one 

preferred embodiment of how responses are handled when 
received through transport 160 on desktop computer 4. 

The user first inputs information through an 
appropriate user interface which defines the user's 
25 response to the meeting request. The response is then 
transmitted back to desktop computer. 4 through 
transport 160 and communications component 115. This 
is indicated by block 204. 

Scheduling application program 152 correlates the 

3 0 response to the meeting object, as did mobile device 

3, by utilizing the global identification number 
assigned to the . meeting object, and received along 
with the response to the meeting request . . This is 
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indicaced by block 206. The time stamp information 
is then checked to determine whether the response 
corresponds to the latest meeting object, again as 
described above. If not, the response is rejected or 
5 ignored as an out-of-date response. This is indicated 
by block 207. Scheduling application program 152 then 
calls the necessary methods exposed by API 158 to 
modify and update the attendee status of the meeting 
object stored in object store 8. This is indicated by 

10 block 208. Desktop computer 4 then simply waits until 
it is next coupled to mobile device 3 . 

At that point, the updated objects in object 
store 8 (which have been updated to accurately reflect 
the new attendee status based on the response) are 

15 synchronized to the other instance of that object then 
stored in object store 6. Synchronization is 

accomplished in accordance with the synchronization 
protocol discussed above. The updated object is then 
available for review and manipulation by the user of 

20 mobile device 3. This is indicated by blocks 210 and 
212 . 

The mobile device in accordance with an 
illustrative embodiment of the present invention also 
handles exceptions to recurring meetings and meeting 
25 cancellations. In one embodiment, the scheduling PIM 
erases all exceptions when an update to the recurrence 
pattern of a recurrent meeting is received. Thus, new 
electronic mail objects must be created and sent for 
each exception once a change in the recurrent meeting 
pattern has been sent. For instance, assuming the 
user entered a recurring meeting request on mobile 
device 3. Scheduling application 142 creates a 
recurring meeting object and enters it on -the calendar 
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of the user. Electronic mail application 140 also 
creates an electronic mail recurring meeting request 
object for transmission to potential attendees. The 
recipients (potential attendees) can respond generally 
5 as described above. 

For the sake of the present example, assume the 
recurring meeting is to occur every Tuesday from 
10:00-11:00 a.m. beginning on April 1. However, the 
user (originator) then needs to cancel the April 8^*" 
10 meeting. The user enters scheduling application 142 
and deletes the desired instance. Electronic mail 
application 140, in turn, creates another object for 
transmission which indicates this cancellation (which 
is an exception to the recurrence pattern) . The 
15 originator then needs to move the April 15th meeting 
to 11:00-12:00 noon . A similar process is executed to 
create this exception as well. Suppose then that the 
originator wishes to make a change to the location of 
the recurring meetings and apply the change to the 
2 0 entire recurrence pattern. This requires three n^w 
pieces of electronic mail to be transmitted • 

The first is simply created to indicate the new 
location which modifies the recurrence pattern. This 
may also, in some PIMs, erase the previous two 
25 exceptions. Thus, two new pieces of electronic mail 
are created to reinstitute the two exceptions (i.e., 
the cancellation of the April 8^^ meeting and the time 
change for the April 15^*" meeting) . These pieces of 
electronic mail are automatically created by 
30 electronic mail application 140. These same actions 
are taken in response to other suitable modifications 
as well, such as modification of the list of 
attendees . 
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LOCALIZATION 

As previously discussed, in the preferred 
embodiment, a meeting object is typically accompanied 
by a textual phrase which describes the nature of the 
5 meeting request. The textual phrase is generated 
based upon the property values input by the user 
during creation of the meeting request. For example, 
a user may request the potential attendees to attend a 
meeting on the third Monday of each month at 10:00 

10 a.m., and for a period which extends from January 1, 
2000, to March 20, 2001. In that case, a typical text 
message which might be retrieved and placed in the 
meeting request object to accompany that object for 
display to the potential attendees might read as 

15 follows; 

"This meeting shall take place on the third 
Monday of each month at 10:00 a.m. beginning January 
1, 2000, and ending March 20, 2001." 

However, in a different locality, convention may 

2 0 dictate that the day be placed before the month when 

reciting dates. Further, words or phrases in the text 
'message, and the order of the components of the text 
message, may need to be rearranged in order to more 
closely conform to local convention. 
25 In the preferred embodiment, a predetermined text 

message of the type set out above is generated to 
describe each different type of recurring meeting 
which can be requested by the user of mobile device 3 . 

In accordance with one aspect of the present 

3 0 invention, the text messages used to describe requests 

for recurring meetings are broken down into a 
plurality of phrases. Each of the phrases which has 
been created is broken down into a plurality of 
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fields. The particular phrases which can be created 
to define a meeting request, and the particular fields 
into which those phrases are separated can be any 
suitable phrases and fields.. 

For the phrase mentioned above, FIG. IIA 
illustrates one embodiment of the fields into which 
that phrase can be broken. FIG. IIA shows that a 
first portion of the phrase "This meeting shall take 
place on the third Monday of each month" is placed in 
field 214. The term "at" is placed in field 216. The 
time designation "10:00" is placed in field 218 and 
the AM/PM designator is placed in field 220. The term 
"beginning" is placed in field 222, and the remaining 
message is similarly broken up into fields 224, 226, 
15 228, 230, 234, 236, 238, 240 and 242. 

FIG. 10 is a flow diagram illustrating how the 
localization process works. The creation of the 
textual phrases defining meeting requests, and the 
breaking up of those requests into various 
20 predetermined fields, is indicated by block 242. 

Next, during manufacture of mobile device 3, a 
localizer program is run on mobile device 3 to 
rearrange fields 214-240, for each of the messages 
created, such that the messages conform to local 
25 convention. Of course, the specific localizer program 
which is run on mobile device 3 will depend on the 
particular locality and consumer base for which mobile 
device 3 is intended. Once the localizer program has 
been run, mobile device 3 contains a plurality of sets 
of fields, referred to as templates, into which 
message data is placed in order to display the textual 
message in a localized fashion. Running of the 
localizer program in setting up the templates is 
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indicated by block 244 . 

After mobile device 3 has templates which have 
been localized, mobile device 3 is ready to receive a 
meeting request and properly display the textual 
5 description of the meeting request. When a meeting 
request is received, the data stream indicative of the 
textual phrase which describes the meeting is also 
received by scheduling application program 142. This 
is indicated by block 246. Scheduling application 
10 program 142 parses the incoming data stream into 
values associated with the various fields in the 
appropriate template (the appropriate template 
corresponds to the specific textual description being 
received). This is indicated by block 24 8. 
15 Next, the parsed data is placed into preselected 

fields in the templates based on the created phrases. 

This is indicated by block 250. Because the 

localizer program has already been run, the fields in 
the templates are already placed in appropriate order 
20 to conform to local convention. 

FIG. IIB illustrates the rearrangement of the 
fields in the template illustrated in FIG. IIA to 
conform to a different convention. FIG. llB 

illustrates the conformation of the phrase to 
convention in which the phrasing is slightly different 
from that shown in FIG. llA, and in which the day is 
conventionally placed prior to the month in a date. 
The phrase now contains the same terms, but reads: 

"Beginning 1 January, 2000 and ending 20 March, 
2001 this meeting shall take place on the third Monday 
of each month at 10:00 AM." 

All appropriate phrases will, of course, be 
similarly localized. 
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Also, in an illustrative embodiment, time zone 
information is handled in an advantageous manner. For 
instance, when a recurring meeting . request is created 
and sent to a device located in a different time zone, 
5 the textual phrase indicative of the recurring meeting 
includes an indication of the time zone in which the 
recurring meeting request was created. For instance, 
if a user in Paris sends a recurring meeting request 
to a recipient in Seattle (nine hours different) for a 
10 meeting occurring every Tuesday at 8:00 a.m. beginning 
March 3 , the textual phrase may be : 

"This meeting occurs every Tuesday at 8:00 a.m. 
beginning March 3; (GMT + 1) Paris, Madrid." 

This allows the recipient to view the recurrence 
15 pattern as originally composed by the sender. 

On the other hand, if the meeting is non- 
recurrent, the time is preferably simply displayed as 
the appropriate time for the recipient (e.g.. "This 
meeting is scheduled for Tuesday at 11:00 p.m."). 
2 0 CONCLUSION 

Therefore, it can be seen that the present 
invention provides significant advantages over prior 
systems. First, the present invention allows the 
creation of a meeting request from a mobile device 
25 itself. The present invention further identifies the 
object associated with such a meeting request in a 
manner which uniquely identifies the object to all 
other devices likely to encounter the object. The 
present invention also utilizes a feature in the PIMs 
3 0 which indicates whether the meeting request has been 
sent to potential attendees. These features eliminate 
duplicate messaging . 

The present invention also preferably implements 
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features which reduce the memory required to implement 
the meeting request feature by use of an abridged 
address book. Further, the present invention 

preferably uses a set of scheduling properties which 
5 are compatible with a plurality of different PIMs 
likely to encounter the meeting request. m addition, 
the present invention preferably utilizes localization 
procedures which localize meeting requests to more 
closely conform to local convention and handle time 

10 zone information in an advantageous manner. The 
present invention also preferably supports the use of 
multiple electronic mail transports as well as a 
synchronization protocol. 

Although the present invention has been described 

15 with reference to preferred embodiments, workers 
skilled in the art will recognize that changes may be 
made in form and detail without departing from the 
spirit and scope of the invention. 
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{autonumigl } Audience/About this document 

This document describes the message properties used by Schcdulc+ 2.0 to transmit meeting 
infonnation to another Schedulc+ 2.0 user. The document also describes Uie Schcduie-i- 1 .0 counteipan 
message properties (where appropriate).. 

The reader should be familiar with MAPI, specifically properties stored on messages. The reader 
should also be somewhat familiar with MAPI 0 properties and how Schedule^ 1.0 used them to 
transmit meeting information. 



{autonumigl } Consumers 

This document is intended for third-party developers who plan to interact with Scheduled 2.0 via 
emaiL 



{autonumigl } The Design 

Schedulc+ 2.0 stores properties of a meeting in similarly typed MAPI properties in a message. 
Typically, the subject of the message matches the description of the meeting (as it did 1.0), and the 
body of the message contains the meeting notes (new for 2.0). The addressees of a meeting request or 
cancellation are compiled from the list of attendees in the meeting, filtered on who should actually 
receive tlus mail The addressee for meeting responses is Ae meeting originator. Senders and 
recipients are ananged properly for delegate handling. See the MAPI spec on how to interpret tfiesc 
standard properties. 

For mail systems that do not automatically handle delegation of mail, Schedule+ 2.0 will open each 
addressee's schedule file (or equivalent) to determine if n?':I iliuuld be sent to a delegate instead of or 
in addiUon to the intended recipient Abo, Schedulc+2.0 will determine if the sending user is mailing 
on behalf of someone else and stamp appropriate properties into the message. The MAPI 1.0 
properties which control delegation arc PRjSEhrr_I^PRESEhrnNGjCENTRYID/NAME) and 
PR.RCVD_,REPRESENTrNG_(ENTRYID/NAME). See the MAPI 1.0 spec on how these properties 
are set to induce delegation. 

Beyond the standard properties, Schedule+ 2.0 defmes and uses private properties which have no 
"normal" messaging counterpart. There are two basic kinds of communication between a meeting 
organizer and an attendee: some notification related to a single meeting, or some notification related to 
a recurring meeting. For backward compatability, the recurring notifications are formatted as a 
superset of single-instance notifications. This way. Scheduled 1.0 users will at least see a well-formed 
meeting notification. 

As in version 1.0. Schedulc+ 2,0 differentiates the type of meet'mg notification by the mail message 
class. The class names have changed slightly since l.O. 



Version 1.0 Class name 


Version 2.0 class name 


Description 


IPM.Microsoft Schedule.MtgCncl 


lPM.Schedule.Meettng.Canceled 


Meeting Cancellation notice. From 
originator 


IPM.Microsoft Schcdulc.MtgRcq 


IPM.SchedulcMecting.Rcqucst 


Meeting Request. From originator 
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IPM.Microsoft 
ScheduicMtgRespN 



IPM.Microsoft 
ScheduIcMtgRespA 



lPM^cliedulc.Mccting.Rcsp.Tcnt 



Meeting Declined, from attendee 



Meeting Tentatively Accepted. 
From attendee 



(autooumlgl JPropertiesoa Single Instance Meetings ' 



as so. 



retnains useful even if the data is 



{autonumlgl } PR.START,DATE 

(autonumlgl} PR_END_DATE 

UTC-adjosted ending dateftime of the appomiment. Must be present 
{autonumlgl} PR_OWNEn_CRmCAL_CHANGE 

correctorder(m^r^;f4t1^^Jr£^"^^^ 

of a meeting. It must be present on all meeting maiT '^'^ ''^ 

{autonumlgl } PR_ATTENDEE_CRITICAL_CHANGE 

This is an increasing value based on the time of th^ lactr..,^ ^ 

insure responses are processed in the eo.»^ oi.r / . "^^^ " «° 

o^^er-s clocU. Whenareclpientreadstheree^r?,^^^^ 

s compared against the previous value (&om a prior bookine^ to s« if " i^V-^"^^°^ 

.s. the recipient may respond as desired. The res^L^lt hfy^a ^ov^f r"'" T *" " ' 
PR_OWNER_CRrnCAL_CHANGE and will sL^ the «a«VtS„ 

PR_ATTENDEE_CRITICAL_CHANGE(accordin^o.h"^SpLrscloc^ V,hc„ ., 

the response, the PR_OWNER_CRITlCAL CHANGE will be comLr^H 

in the appointment to decide iflhe response-co^^nds ^tJ^Ts ve^^^^ '^^ 

PR_ATrENDEE_CRITlCAL_CHANGE is comp^d >X« Z p^t££:^T"^^^^^ 

received from .his user to decide if the response itself is L^r '"""""'P '"Ponscs 
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(autonumigl } PR_WHERE 

A descriptive string describing where the meeting will be held (no I.O counterpart). The text of this 
string will also appear in the body of the note so that non-Schedule+ users will still sec some uschil 
tnfonnation. In ZO, the embedded body text will be removed before it is displayed or wrinen into the 
schedule. 

(autonumigl } PR_GLOBAL.OBJID 

a "globar ID for the meeting. This ID uniquely and universally ID'S the meeting or recurrence panem. 
Its internal structure is: 

+0 bytes: OUID idenit^g client vendor. For Microsoft Scheduled 2.0. this GUID is 

0x04. Oxo2, OxEO, 0x74, OxC5, OxB7, 0x10, 0x1 A, 
0x82, OxEO, 0x08, 0x00, 0x2B. 0x36, OxA3, 0x33 

Other vend-^rs should use their own GUID. 

+16 bytes: Implementation specific data. 

If this properly is missing, the attendee tracking features will be disabled. This means further 
notificattons concerning the meeting will not be properly handled by the recipient, and the 
recipient will not be able to commtmicate attendee status properly with the originator. 

(autonumigl } PRJREQUIRED_ATTENDEES 

If present, lists all the invited *i«quircd" atteadees. The string is a concatenated form of the display 
names of each required attendee, separated by semicolons. The intent is the string itself may be placed 
in the **To:" well of a mail message when die original meeting request is Replied or Reply-Aired, ai«U 
the names will directly resolve into real recipients. 

{autonumigl } PR_OPnONAL_ATTENDEES 

If present, lists all the invited '*optionaI" attendees. The string is a concatenated fonn of the display 
names of each optional attendee, separated by semicolons. The intent is the string itself may be placed 
in the "CO" well of a mail message when the original meeting request is Replied or Reply-AlPcd, and 
the names v/Ul directly resolve into real recipients. 

{autonumigl } PR_RESOURCE_ATTENDEES 

If present, lists all the invited "resource" attendees. The string is a concatenated form of the display 
names of each resource attendee, separated by semicolons. The intent is the string itself may be placed 
in the "BCC:" well of a mail message when the original meeting request is Replied or Reply-All'cd. 
and the names will directly resolve into real recipients. 

{autonumigl} PR_PROCESSED 

If present and TRUE, mdicatcs that the message's contents have been processed (ie. for responses, the 
user's response code has been incorporated back into the owner's schedule). This property is not 
transmitted and is written only by the Schedule+ 2.0 client after the message has successfully been 
processed. 



SUBSnnnESHEEr(Rlil£28) 

BNSDCXJID: <WO 9922324A1J_> 



wo 99/22324 

PCT/US98/224I3 



54 



{auconumlgi } FRJS^SILENT 

^«eforc tf,e ™„ should be processed and detae^foiS.-^^ '° 
{aut-numlg,, PR_WANT_SILEm-_RESP 

This is used hi tandem with PR BESPOWP DCrt.,.^. 

{autonumlgl} PR_DELEGATE_MAIL 
If present and TRUE, indicates that th^ 
d<U^ans,«egy.,fson,«?e^SL,S%TTn^ 

dcieg«e before the„«u,i.^j,«,(,^*«P;^o;-^^^ 

the concern of any other developetr. ^ ^ ™^ ««'^«»'* " MAPI, and shouldn^ 

{aatoaamlgl, P»_ruaPONSE_REQUESTED 

If present and TRUE, indicate* th^t *u 

with meaningful tc^cT^VTl^i^T^ ""T '"'^ ««e»«lecs send a resnon. 

««di«.esthese„derVwnyKo^£J^:[^^^ 

^e. ll,e«cipicot (attendee) wiU „ot be SS. ^ri^Z^'"'^'^'^ ''^^''"'^ ipox^c 
response message will be sent and auto-p4<^lwh Howev^ a 

-'P'^-H'beab.e.oove.dethisbe^a'S^rSL'r^^^^^^^ 
{aotonumlgl} PR_OWNER_APPT_ID 

(^nljtrit^^^^ 

'«ve this propertj. blank. coramuntcating with I.O). Other clients should 

"^^^^^^"^^^^^ 

{autonumlgl} PR_rS_RECURRING 

If present and TRUE, indicates that this request is fnr» ■ • 

request is for a smglc insumcc of a panem. 
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(autonumlgl ) PRISING LE^INVITE 

If present and TRUE, indicates that this request is an inviution to the single instance only The 
recipient is not invited to the rest of the panem. 

(autonumM ) PR_TIME_ZONE 

Desribes the owner's time zone (TBD - no woric on time zones has been done yet). Must be present for 
recurring meeting requests. 

{autonumlgl } PR_START_RECUR_DATE 

The start date of the recurrence pattetti in the origmalor's local lime zone. Its encoded by 
((long)yrad.yr * 1 6! + aong)ymdjnon) • 321 + (long)ymd.day. If s stored as a long so gateways wont 
mterprct the date as if it were in GMT and possibly muck with it Must be present for rccurxing 
meeting requests. 

{autonumlgl } PR_START_RECURjnME 

The start time of the pattern in the originator's local time zone encoded by: ((long)tiinc hr • 641 + 
(long)tunejnm) • 641 + (long)timc jec Same reason for encoding. Must be present for recurring 
meeting requests. ** 

{autonumlgl } PR_END_RECUR_DATE 

If present, holds the end date for the pattern. If missing, the pattern runs forever. See 
PR_START_RECUR_DATE for encoding method. 

{autonumlgl } PR_END_RECUR_TIME 

The end time of the pattern. Sec PR_START_RECUR_TIME for encoding. Note that unless the first 
mstancc of the pattern is an exception, the start date/time and end time for the pattern will co'uicide 
with PR^START.DATB and PR^END.DATE in this message. T.Iust be present for recuning meeting 
requests. 

{autonumlgl } PR_DOW_PREF 

Describes the Isi day of user preference. This is for multi-day weekly patterns that have an 
mterval greater than one. Imagine a pattern that's every two weeks on Sunday and Monday starting on 
the IsL If the first day of week is Sunday the 1st. the pattern will consist of 1, 2. 15. 16 etc If the first 
day of week is Monday, the pattern will be 2. 8, 16, 22. etc. Must be present for recurring meeting 
requests which describe a weekly pattern where the week interval is greater than 1. 
{autonumlgl } PR_RECUR_TyPE 

Describes the type of rccunrence. One of trecurDaily (0x40). trecurWeekly (0x30) trecurMonthly I 
(OxOC). trecurMonthly2 (0x38). trccurYearlyl (0x07). trecurYcarly2 (0x33). Must be present for 
recurring meeting requests. 

{autonumlgl } PR^DAY^ITTTERVAL 

Describes the delta in days between instances of this pattern. If missing and required for the pattem 
type, it is assumed to be I. 

{autonumlgl } PR_WEEK_INTERVAL 

Describes the delta in weeks between instances of this pattern. If missing and required for the pattern 
t>'pe. it is assumed to be I . 

{autonumlgl ) PR_MONTH_lNTERVAL 

Describes the delta in monUis between instances of this pattern. If missing and required for the pattern 
t^-pe, it is assumed to be 1 . 
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(autonumtgl) PR_YEAR_INTERVAL 

Describes the delta in years between instances of this paaem. If mtssing and required for the pattern 
type, it is assumed to be I. 

(autonumtgl } PR_DOW_MASK 

Bit field (bit 0 = Sunday) whidi describes which days or the week arc valid in tliis paaem. If missing 
and required for the pattern type, it is assumed to be 2*-l (alt days). 

{autonumtgl } PR_DOM_MASK 

Bit licld (bit 0 « day 1) which describes which days of any given month are valid in this pattern. If 
missing and required for the pattern type, it is assumed to be 2^- 1 (all days). 

(autonumtgl ) PR_MOY_MASK 

Bit field (bit 0 = January) whidi describ«:s which months in any given year arc valid in this panem. If 
missing and required for the pattern type, it is assumed to be 2 -1 (ail months). 
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Appendix A: Property Definitions ' " 

Properties defined by MAPI for S+ backwards compatibility: 

PR.START^DATE 
PR_END_DATE 
PR_RESPONSE_REQUESTED 
PR_OWNER_APPTJD 

Non-transmitted properties used by S+: 

#dcfmcPR_PROCESSED PROP.TAG( PT_BOOLEAN. Ox7d01) 

We use named properties for the remaining definitions. 

GUID - (OX6RD8DA90. <hc4S0B. OxIOIB. 0x98. OxDA, 0x00. OxAA..OxOO. Ok3F. 0x13. 0x05) 

Name 

ATTENDEE^CRrnCAL CHANGE 
WHERE 

GLOBAL_OBJID 

IS^SILEhTT 

IS_RECURRING 

REQUIRED^ATTENDEES 

OPTIONAL^AITENDEES 

RESOURCEATTENDEES 

DELEGATE MAIL 

IS^EXCEPTTON 
SINGLE^INVITE 
TIME__20HF 
START^RECUR^DATE 
START_RECUR_TIME 
END_RECUR_DATE 
END_RECUR_TTME 
DAY^INTERVAL 
WEEK^INTERVAL 
MOhrrH_mTERVAL 
YEAR_mTERVAL 
DOW^MASK 
DOM^MASK 
MOY_MASK 
RECUR_"m>E 
DOW_PREF 

OWNER_CRITICAL_CHANGE 



LID 


PropType 


I 


PT^SYSTIME 


2 


PT_TSTRrNG 


3 


PT_BINARY 


4 


PT_BOOLEAK 


5 


PT.BOOLEAN 


6 


PTTSTRING 


7 


PTTSTRING 


8 


PT^TSnUNG 


9 


PT.BOOLEAN 


10 


PT_BOOLEAN 


H 


PT BOOLEAN 


12 


PTJ4 


13 


PT 14 


14 


PTJ4 


15 


PTJ4 


16 


PTJ4 


17 


PT_I2 


18 


PTJ2 


19 


PT 12 


20 


PT 12 


21 


PTJ4 


22 


PT 14 


23 


PT 14 


24 


PT 12 


25 


PT_I2 


26 


PT_SYSTIME 
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The following table associates the SchedolM- i n 
«h«c properties are def.ncd by MAPI , .0 f^ba^lS^'^V '° ^ ^ «>-««P3as. All of 



attOwner 



attScntFor 

actDeiegate 

attWhea 

attAidLocal 

attOateStart 

attOatcEnd 

atCAidOwner 

attRequestRes 



" »s a mtg Tcq or cancellauon 

o^;S^-'^'^^«-<^^'>/NAME) 

PP«^S?J!f''"^'"*e'«l or cancellation 
roi^r^™^«-^VID,HAME) 

'"""""•^ 

PR^START^DATE 
PR_END_DATE 
PR_OWNER_APPT_ID 
PR_R£SPQNSE_R£QUEST£D 
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A'ppendix C: Scheduled l.O property definitions 



^define anOwner 
^define aaScntFor 
#definc attOelpgate 
^define art When 
^define atlAidLocal 
^deftne attDaieStart 
^define atiDateEnd 
#de£ine attAidOwner 
Mcftne attRequestRes 



FormAttC 
FonnAa( 
FonnAtt ( 
FormAtt ( 
FomiAtt ( 
FormAtt ( 
FomiAtt ( 
FonnAtt ( 
FonnAtt ( 



iattClicntMin-K), 
iattClientMin+1, 
iattClicntMin+2, 
iattOientMin-i-4, 
iattCifentMin+5. 
tattCIientMin+6, 
iattCIicntMin+7, 
iattOientMin+S, 
iattCiientMin+9, 



atpByie ) 
atpBytc ) 
atpBytc ) 
atpSiring ) 
atpLong) 
atpDatc ] 
atpDate ) 
atpLong) 
atpShort ) 



Sec the MAPI 0 documentation for the meaning of these macros 
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* SPLUSTAGS.H 

Copyright 1986-1997 Microsoft Corpoi 



oration. All Rights Reserved. 



#ifndef SPLOSTAGS H 
#define SPLUSTA6S~H 



tdefine HHPR_START DATE 
IME, 0x0060) ~ 
Sdefine HHPR end DATE 
IME, 0x0061} ~ 
#define HHPROWNER APPT ID 
' 0x0062) ~ ~ 



#define 
liETIME,. 
^define 
LETIME, 
#define 
WSTR, 

#define 
OB, 

# define 
WSTR, 
#define 
WSTR, 

#define 
WSTR, 



HHPR_WHERE 

0x0066) 
HHPR_GLOBAL OBJID 
0x0067) 

HHPR_REQUIRED ATTENDEES 
0x0068) 

HHPR^OPTIONAL ATTENDEES 
0x0069) 

HHPR_RESOURCE ATTENDEES 
0x006a) 



nde fine 
^define 
#define 
"define 
#def ine 

r 

*fdef ine 
* 

^define 
#def ine 



HH PR_IS_SILENT 

0x006c) 
HHPR^WANT SILENT RESP 

0x006d) " 

HHPR_DELEGATE MAIL 
0x006e) ~ 

HHPR_ls_RECURRING 
OxOOGf ) 

HHPR_ls_EXCEPTION 
0x0070) 

HHPR_SINGLE INVITE 
0x0071) " 

HHPR_TlME_ZONE 
0x0072) 

HHPR_^START_RECUR DATE 



PROP_TAG( PT^SYST 
PROP_TAG{ PT^SYST 
PROP_TAG( PT^LONG 
PROP_TAG( CEVT_X2 



PROP_TAG ( 
PROP_TAG ( 
PROP_TAG ( 
PROP_TAG ( 
PROt-^TAG ( 
PROP_TAG { 
PROP TAG( 



CEVT_FI 

CEVT_FI 

CEVT_LP 

CEVT_BL 

CEVT_LP 

CEVT_LP 

CEVT LP 



PROP_TAG( CEVT_I2 
PROP__TAG( CEVT_I2 
PROP_TAG( CEVT_I2 
PROP_TAG{ CEVT_I2 
PROP_TAG( CEVT_I2 
PROP_TAG( CEVT_I2 
PROP_TAG( CEVT_I4 
PROP__TAG( CEVT 14 ^> 



BNSDOCID: <WO_9922324Al 



2Si 



wo 99/22324 



PCT/US98/22413 



61 



0x0073) 

^define HHPR_^START RECUR TIME 

0x0074) ^ PROP_TAG( CEVT_I4 
# define HHPR_end_RECUR DATE 

0x0075) " PROP_TAG( CEVT_I4 
« define HHPR_end_RECOR timl 

0x0076) " PROP_TAG( CEVT_I4 
#d-fine HHPR_DOW PREP 

0x0077) PROP_TAG( CEVT_I2 
^define HHPR__RECUR TYPE 

0x0078) ^ PROP_TAG( CEVT_I2 
#define HHPR_DAY INTERVAL 

0x0079)- PROP_TAG( CEVT_I2 
#define HHPR_WEEK INTERVAL 

0x007a) " PROP_TAG( CEVT_I2 
#define HHPR__month INTERVAL 

Ox007b) - PROP_TAG( CEVT_I2 
#define HHPR_YEAR INTERVAL 

Ox007c) " PROP_TAG( CEVT_I2 
#define HHPR_DOW MASK 

0x007d)'' PROP_TAG{ CEVT_I4 
#define HHPR_DOM MASK 

0x007e)" PROP_TAG( CEVT_I4 
#define HHPR_moy MASK 

0x007t)'" PROP_TAG{ CEVT_I4 

//Non-transmitted property (not named) 
#define HHPR PROCESSED 

0x7d01) " PROP_TAG( CEVT_I2 

#ifndef HHPR_TAf=_c::LY 

static ULONG SPlusNamedTagTypes f 30] = f 
PT_SYSTIME, ^ -r^- I J i 

PT_STRING8, 

PT_BINARY, 

PT_BOOLEAN, 

PT_BOOLEAN, 

PT_STRING8, 

PT_STRING8, 

PT_STRING8, 

PT_BOOLEAN, 

PT_BOOLEAN, 

PT_BOOLEAN, 

PT_I4, 

PT_I4, 

PT_I4, 

PT_T4, 

PT_I4, 

PT_I2, 

PT_I2, 

PT 12, 
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PT__I2, 

PT_I2, 

PT_I2, 

PT^SYSTIME, 
PT_SYSTIME, 
PT^SYSTIME, 
PT_BOOLEAN, 
PT_I4 } ; 

static OLONG SPlusNamedTaos f ^ni 

HKPR_GLOBAL OBJID 
HHPR_IS_SILENT, ' 
HHPR_IS_REC0RR1NG, 
HHPR REQUIRED_ATTENDEES , 
«uf ^-°^^^°^^-ATTENOEES , 
»«»^-^^°"^'=^-ATTENDEES, 
HHPR_DELEGATE MAIL 
HHPR_ls_EXCEPTION, ' 
HHPR_SINGLE INVITE 
HHPR_TIME_ZONE , 

DATE, 

HHPR_START_RECt;R~TrME 
HHPR_END_RECOR DATE ' 

HHPR_END_RECUR~TIME ' 
HHPR_DAY_INTERVAL, ' 
HHPR_WEEK_INTERVAL, 
HHPR_MONTH_lNTERVAL 
HHPR_ YEAR INTERVAL, ' 
HHPR_DOW_MASK, 

hhpr_dom_mask' 

HHPR_MOY_MASK, 
HHPR_REcur_T YPE , 
HHPR_DOW_PREF 

rtHPR^START DATE 
HHPR_END_DATE, 

Muno-^^^^^^^^l^^QUESTED, 
HHPR_OWNER_APPT_I D} ; 

#endif // HHPR^TAG^ONLY 

#enciif /* SPLUSTAGS H */ 
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WHAT IS CLAIMED IS: 

1. A mobile device, comprising: 
an object store; 

an application program configured to maintain 

objects on the object store; 
a user input mechanism configured to receive 

user input information; 
a synchronization component configured to 

synchronize individual objects stored on the 

object store with remote objects stored on a 

remote object store; 
a communications component configured to 

communicate with a remote device containing 

the remote object store; and 
wherein the application program is further 

configured to generate a meeting object and 

an electronic mail meeting request object 

based on the user input information. 

2 . The mobile device of claim 1 wherein the 
application program is configured to generate the 
meeting object with a global identifier property 
uniquely identifying the meeting object among a 
plurality of other objects. 

3. The mobile device of claim 2 wherein the 
application program comprises: 

a first application program configured to 

generate the meeting object based on the 
user input information; and 

a second application program configured to 

generate the electronic mail meeting request 
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object . 

4 . The mobile device of claim 1 wherein the 
application program further comprises: 

a contacts application program configured to 
maintain objects on the object store 
indicative of contact information wherein 
the contact information includes address 
information indicative of a fully qualified 
electronic mail addresses for individuals 
identified by the contact information; and 

wherein the application program is configured to 
obtain the fully qualified electronic mail 
address of potential attendees identified by 
the contact information by interaction with 
the contacts application program. 

5. The mobile device of claim 1 wherein the 
application program is configured to generate the 
meeting object and the electronic mail meeting request 
object such that properties of the objects are 
compatible with at least a second application program 
associated with the remote object store and different 
from the application program. 

6 . The mobile device of claim 1 wherein the 
application program, is configured to receive a data 
stream indicative of a textual phrase describing the 
meeting object, to parse the data stream into sections 
and place the sections in corresponding fields of a 
preselected template containing the fields, the 
preselected template being associated with the textual 
phrase received. 
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7 . The mobile device of claim 6 wherein the 
preselected template is created by arranging the 
fields in an order, the order being based on a 
specific locality. 

8. A method of operating a mobile device, 
comprising : 

providing a first object store on the mobile 
device; 

providing a first application program on the 

mobile device; 
maintaining objects in the first object store 

with the first application program; 
intermittently synchronizing the objects in the 

first object store with objects in a remote 

object store; 
receiving user input information indicative of a 

meeting request; 
generating a meeting object with the first 

application program such that at least some 

of the user input information defines 

properties in the meeting object; 
generating an electronic mail meeting request 

object based on the information in the 

meeting object; and 
. storing the meeting object and the electronic 

mail meeting request object in the first 

object store for transmission. 

9. The method of claim 8 wherein synchronizing 
comprises: 

coupling the mobile device to a computing device 
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10 , 



having the remote object store ; 
synchronizing objects in the first data store 

with objects in the remote data store; and 
transmitting the electronic mail meeting request 
from an electronic mail transport on the 
computing device. 

The method of claim 8 and further comprising: 
providing an electronic mail transport on the 

mobile device; and 
transmitting the electronic mail meeting request 
object through an electronic mail transport 
on the mobile device. 

11. The method of claim lO wherein providing an 
electronic mail transport on the mobile device 
comprises : 

providing a plurality of electronic mail 
transports on the mobile device; and 

the plurality of electronic mail 
transports through which the electronic mail 
meeting request objects are to be 
transmitted. 

12. The method of claim 11 wherein generating a 
meeting object further comprises: 

assigning the meeting object a time stamp 
indication indicating a time when the 
meeting object was created; and 

wherein generating the electronic mail meeting 
request object includes assigning the 
electronic mail meeting request object the 
time stamp indication. 
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13. The method of claim 12 and further comprising: 
receiving response objects; 

correlating the response objects with the meeting 
object on the mobile device based on the 
global identifier and the time stamp 
indication; and 

updating a response status associated with the 

meeting object based on the response objects 
received. 

14. The method of claim 13 and further comprising: 
synchronizing the response status with the remote 
object store. 

15. A data transmission system, comprising: 
a first computing device including: 

a first data store configured to store objects; 
a user input mechanism; and 

a first application program configured to receive 
user input information from the user input 
mechanism, create a first object based on 
the user input information and store the 
first object on the first data store; 

a synchronization manager configured to 

synchronize objects in the first data store 
with objects in a second data store; 

a second computing device including: 

the second data store, the second data store 
being configured to store objects; and 

a second application program configured to access 
the second data store and create an 
electronic mail object based on the first 
object being synchronized to the second data 
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store from the first data store; 
an electronic mail transport; and 
wherein the second application program is 

configured to transmit the electronic mail 
objects with the electronic mail transport. 

16. The system of claim 15 and further comprising: 
a third computing device including: 

a third data store configured to store objects; 
and 

a third application program configured to access 
the third data store, to receive electronic 
mail objects from the second computing 
device and to store the electronic mail 
objects on the third data store. 

17. The system of claim 16 and further comprising: 
a fourth computing device including: 

a fourth data store; and 

a fourth application program configured to 
access the fourth data store and store 
objects on the fourth data store; and 

wherein the synchronization manager is 

configured to synchronize objects in 
the third and fourth data stores. 

18. The system of claim 17 wherein the 
synchronization manager comprises: 

a first synchronization manager on at least one 
of the first and second computing 
devices; and 

a second synchronization manager on at least one 
of the third and fourth computing 
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devices . 

19. A mobile device, comprising: 
an object store ; 

a user input mechanism configured to receive user 

input values; 
a plurality of electronic mail transports; and 
a first application program configured to create 
an object based on the user input values and 
to transmit the object using a preselected 
one of the electronic mail transports. 

20. The mobile device of claim 24 and further 
comprising : 

a housing sized to hold the object store, the 
application program and the plurality of 
electronic mail transports and to fit in the 
hand . 
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